add support for package extensions #3264
Conversation
Make `Pkg.precompile` work with glue packages
|
Tweaked the printing for glue pkgs in precompilation:
|
|
Status output:
Shows you glue packages and glue dependencies and which ones are loaded (in green). |
|
Awesome. Should there be a + before the enabled glue packages or something, so that it's not just color |
|
Yeah, I can add that |
Co-authored-by: Ian Butterworth <[email protected]>
Co-authored-by: Ian Butterworth <[email protected]>
Co-authored-by: Ian Butterworth <[email protected]>
docs/src/creating-packages.md
Outdated
| callback only when glue packages are not supported | ||
| ```julia | ||
| # This symbol is only defined on Julia versions that support glue packages | ||
| if isdefined(Base, :get_gluepkg) |
There was a problem hiding this comment.
| if isdefined(Base, :get_gluepkg) | |
| if !isdefined(Base, :get_gluepkg) |
If I understand correctly?
|
Should this also include a REPL command to add glue packages, or is this experimental enough that the accessibility of a convenient REPL mode isn't desired? Something like |
|
It could be added but it isn't rely necessary for the core functionality so maybe in another PR. |
docs/src/creating-packages.md
Outdated
| objects from a wide variety of different Julia packages. | ||
| Adding all those different Julia packages as dependencies | ||
| could be expensive since they would end up getting loaded even if they were never used. | ||
| Instead, these code required to plot objects for specific packages can be put into separate files |
There was a problem hiding this comment.
| Instead, these code required to plot objects for specific packages can be put into separate files | |
| Instead, the code required to plot objects for specific packages can be put into separate files |
src/Registry/registry_instance.jl
Outdated
| deps::Dict{VersionRange, Dict{String, UUID}} | ||
|
|
||
| # WeakCompat.toml | ||
| glue_compat::Dict{VersionRange, Dict{String, VersionSpec}} |
There was a problem hiding this comment.
So there will be new registry files written for these then? i.e. we'll need to update RegistryTools.jl to support these as well?
There was a problem hiding this comment.
Yes, there already is a branch on LocalRegistry.jl supporting this.
src/Operations.jl
Outdated
| # `julia` is always an implicit direct dependency | ||
| filter!(ctx.env.project.compat) do (name, _) | ||
| name == "julia" || name in keys(ctx.env.project.deps) || name in keys(ctx.env.project.extras) | ||
| name == "julia" || name in keys(ctx.env.project.deps) || name in keys(ctx.env.project.extras) || name in keys(ctx.env.project.gluedeps) |
There was a problem hiding this comment.
I tend to prefer haskey(dict, name) than name in keys(dict)
There was a problem hiding this comment.
Yeah, I just kept the existing way of writing it but that is better indeed.
src/Operations.jl
Outdated
| update_manifest!(ctx.env, pkgs, deps_map, ctx.julia_version) | ||
|
|
||
| new = download_source(ctx) | ||
| fixup_glue!(ctx.env, pkgs) |
There was a problem hiding this comment.
Is it possible to call fixup_glue! from download_source? Or are there cases where we download, but don't want to fixup glue?
There was a problem hiding this comment.
Maybe. Or have another function that calls both of them.
Before this PR we could create the manifest without even having to download the packages. Now, we need to look up the glue packages in the downloaded packages project file since that information is not stored in the registry.
An alternative to this is to not store the glue package mapping in the manifest at all and just look it up in the package's project file in code loading. But we have so far tried to avoid that opting for storing everything required for code loading in the manifest...
KristofferC
changed the title
It is possible to think that `Registry` may be a standalone Pkg command with the previous docstring (e.g. a command that constructs or displays registry info).
Co-authored-by: Lilith Hafner <[email protected]>
`APIOptions` is defined as an alias for `Dict{Symbol, Any}`.
Consequently, the definition of a constructor for `APIOptions`
introduced a new constructor for Dict. This commit removes that
constructor.
`PackageToken` is a Union of multiple struct types. This commit removes a constructor for `PackageToken` and replaces it with a function `packagetoken`. Furthermore, this commit removes `PackageIdentifier` as an alias for String and replaces that with a struct type, which wraps a String containing a package identifier.
7 participants
Requires JuliaLang/julia#47695